Skip to content

fix: add ownership enforcement on character and corporation API endpoints#90

Closed
cchopin wants to merge 1 commit into
eveseat:masterfrom
cchopin:fix/idor-character-api-endpoints
Closed

fix: add ownership enforcement on character and corporation API endpoints#90
cchopin wants to merge 1 commit into
eveseat:masterfrom
cchopin:fix/idor-character-api-endpoints

Conversation

@cchopin
Copy link
Copy Markdown

@cchopin cchopin commented May 11, 2026

Security Fix: Insecure Direct Object Reference (IDOR) on Character/Corporation Endpoints

Vulnerability

The character and corporation API endpoints accepted any valid character_id or corporation_id as a route parameter without verifying that the authenticated API token's owner has access to that resource.

Any holder of a valid API token — regardless of which characters they own — could access the data of any character or corporation registered on the SeAT instance by enumerating or guessing EVE character IDs (which are public and sequential).

Affected Endpoints

All routes under:

  • GET /api/v2/character/{character_id}/* — assets, wallet, mail, contracts, skills, market orders, notifications, industry jobs, jump clones, contacts, etc.
  • GET /api/v2/corporation/{corporation_id}/* — assets, wallet, member tracking, contracts, etc.

Impact

An attacker with any valid API token (even one generated for a non-privileged user) can:

  • Read the complete wallet history and ISK balance of any character on the instance
  • Access private in-game mail of any character
  • Retrieve asset locations and values for any character or corporation
  • Access market orders, industry jobs, and contract details
  • Track member locations via corporation member tracking endpoints

In an alliance context where SeAT is used for auth and intel, this constitutes a full compromise of all member financial and operational data.

Fix

Added CharacterOwnership and CorporationOwnership middleware classes that intercept requests to character/corporation-scoped endpoints and verify that the requesting token's owner has access to the requested resource.

A nullable user_id column is added to api_tokens via a new migration, allowing tokens to be scoped to a specific SeAT user. Backwards compatibility is preserved: existing tokens with no user_id are treated as superuser-scoped and retain unrestricted access. Users with the superuser role also retain unrestricted access to support administrative use cases.

References

… endpoints to prevent IDOR

Introduces CharacterOwnership and CorporationOwnership middleware that verify
the API token owner has access to the requested character_id / corporation_id.
Adds a nullable user_id column to api_tokens so tokens can be scoped to a
specific SeAT user; tokens with no associated user retain unrestricted
(superuser-scoped) access for backwards compatibility.
@recursivetree
Copy link
Copy Markdown
Contributor

Works as intended. Please don't open spam issues.

@Crypta-Eve this should be closed.

@Crypta-Eve Crypta-Eve closed this May 12, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants